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A Mobile  Decision  Aid  for  Determining 
Deteciion  Probabilities  for  Acoustic  Targets 


David  Sauter,  David  Marlin 
Army  Research  Laboratory 
White  Sands  Missile  Pvange,  NM  8800?  USA 


ABSTRACT 

The  Army  Research  Laboratory  (ARL)  has  developed  a physics  based  Acoustic  Battlefield  Aid  (ABFA)  for  acoustic  sources 
and  sensors.  This  application  computes  numerous  output  parameters  (e.g.,  probability  of  detection,  transmission  loss,  signal- 
to-noise  ratio,  etc)  for  a number  of  acoustic  sources  and  sensors  (if  required).  Probability  of  detection  (POD)  output  would 
seem  to  be  particularly  of  interest  to  lower  echelon  units,  e.g.,  in  determining  how  close  enemy  tanks. could  approach  before 
being  heard  (by  either  the  human  ear  or  some  other  acoustic  sensor).  As  a result,  a prototype  application  has  been  developed 
that  allows  the  POD  for  a user  specified  target/sensor  pairing  given  the  direction  and  distance  between  the  two.  Commercial 
wireless  communications  are  used  to  link  the  mobile  device  (a  Compaq  3650  personal  digital  assistant)  to  a remote  laptop 
server.  The  server  consists  of  a set  of  dynamic  linked  libraries  written  in  C that  contain  several  functions  that  access  an 
acoustic  propagation  table.  This  table  is  a function  of  the  environmental  conditions,  and  for  the  prototype,  is  simply  a static 
table.  Eventual  dynamic  creation  of  the  table  from  an  existing  gridded  prognostic  meteorological  database  (residing  on  the 
Army’s  tactical  command  and  control  system  for  weather)  is  anticipated.  Tactical  wireless  comms  would  also  replace  the 
short-range  commercial  comms. 

INTRODUCTION 

While  military  ground  targets  have  traditionally  been  detected  via  their  visible  and  infrared  emissions,  detection  of  their 
acoustic  signatures  can  also  be  used  for  target  acquisition.  For  example,  the  Brilliant  Anti-Armor  Technology  Submunition 
(BAT)  uses  an  acoustic  sensor  to  seek  out  armor  targets,  and  an  infrared  sensor  to  engage  the  vehicles.  As  with  visible  and 
infrared  signatures,  the  atmosphere  can  attenuate  the  transmission  of  the  acoustic  signal.  Realizing  the  requirement  for 
providing  information  regarding  the  acoustic  source  propagation  through  the  environment  and  its  effects  on  the  ability  of 
sensors  to  detect  the  signal,  ARL  researchers  have  developed  an  Acoustic  Battlefield  Aid  (ABFA)  [1].  ABFA  is  a physics 
based  model  that  can  provide  numerous  outputs  regarding  the  acoustic  signal  transmission  through  the  atmosphere.  Some  of 
the  outputs  available  include  probability  of  detection,  direction  finding  accuracy  and  signal-to-noise  ratio.  Inputs  include  the 
meteorological  conditions,  underlying  terrain  type  (forest,  gravel,  sand,  etc)  the  acoustic  source  (target  - T62  at  19  mph, 
generic  tank,  stationary  HMMWV,  etc)  and  receiver  (sensor  - human  listener,  generic  single  microphone,  microphone  array, 
etc).  It  is  currently  available  on  Windows  based  platforms  although  an  effort  is  underway  to  provide  the  ABFA  functionality 
on  the  Army’s  fielded  tactical  command  and  control  system  for  weather,  the  Integrated  Meteorological  System  (IMETS). 
Figure  1 is  a capture  of  a recent  ABFA  graphical  user  interface  and  display  showing  the  detection  probability  for  a generic 
tank  by  a microphone  array.  The  interface  also  shows  a pull  down  source  menu  that  can  be  used  to  select  a specific  acoustic 
source.  Weather  data  can  currently  be  entered  manually,  downloaded  from  the  internet  or  the  user  can  choose  pre-defined 
meteorological  cases,  e.g.,  “clear  night,  moderate  wind”.  When  integrated  into  the  IMETS,  the  weather  data  can  be 
automatically  retrieved  for  the  specified  location  by  accessing  a gridded  database  containing  the  output  from  a prognostic  fine 
scale  weather  model. 

As  can  be  seen  from  Figure  1,  the  ABFA  GUI  is  rather  involved  and  contains  numerous  menu  items  and  options  that  must  be 
set  by  the  user.  This  is  beneficial  in  terms  of  providing  a powerful  and  highly  configurable  modeling  environment,  however, 
for  lower  echelon  users  the  computing  platform  that  they  have  access  to  may  not  be  amenable  to  this  level  of  detail.  In  this 
case,  when  the  majority  of  the  meteorological  and  terrain  data  can  be  maintained  on  a server  platform  (e.g.,  an  IMETS  at 
battalion  level),  a simple  GUI  on  a handheld  computing  device  may  suffice.  This  GUI  would  provide  the  user  with  enough 
flexibility  to  specify  the  basic  input  parameters  (e.g.,  source  and  sensor  as  well  as  azimuth  and  range  between  them)  that  can 
then  be  sent  to  the  server  (over  wireless  comms,  for  instance)  for  computation  of  probability  of  detection  (or  some  other 
output  parameter).  Thus,  critical  quantitative  detection  related  information  could  be  provided  to  lower  echelon  users  on  the 
local  device.  The  remainder  of  this  paper  discusses  such  a prototype  application  that  has  been  developed  and 
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demonstrated  by  ARL. 
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Figure  1 - ABFA  Graphical  User  Interface 


REQUIREMENT 

The  Army’s  Objective  Force  will  emphasize  highly  mobile  and  independent  fighting  units.  To  enable  the  Objective  Force, 
information  and  situational  dominance  will  be  required  at  all  echelons.  This  will  require  providing  critical  information  to  the 
lower  echelons  via  small  computing  devices  (e.g.,  handheld  computers)  over  wireless  communications.  Although  an  IMETS 
will  be  fielded  at  battalion  level  via  a light  version  on  an  Intel  based  hardware  platform,  there  are  currently  not  any  plans  to 
field  an  IMETS  at  echelons  below  this.  In  an  effort  to  address  this  requirement,  the  Army  is  developing  prototype  hardware 
and  software  environments  to  provide  a lower  echelon  computing  capability  on  handheld  or  mobile  computing  devices.  For 
example,  there  are  ongoing  efforts  at  the  Dismounted  Battlespace  Battle  Lab  (Ft.  Benning,  GA),  the  Land  Warrior  Program 
(Ft.  Belvoir,  VA)  and  the  Objective  Force  Warrior  (Natick,  MA)  related  to  mobile  computing  applications.  ARL  is  involved 
in  developing  prototype  applications  specifically  related  to  weather  and  weather  impacts  on  weapon  systems  and  military 
operations,  of  which  acoustic  propagation  is  one. 

Even  though  there  have  been  numerous  technological  advances  in  the  mobile  computing  environment,  it  is  not  yet  feasible  to 
make  all  of  the  required  computationally  intensive  calculations  on  the  mobile  device,  thus  a client-server  environment  was 
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chosen  to  develop  and  demonstrate  our  prototype  Mobile  Acoustic  BattieField  Aid  (MABFA).  The  specifics  of  both  the 
server  and  client  are  discussed  briefly  in  the  following  section. 

CLIENT-SERVER  ENVIRONMENT 

Surrogate  Server 

Detailed  acoustic  propagation  information  is  computed  as  a function  of  the  environmental  conditions  (wind  velocity, 
temperature  profile,  etc)  and  stored  in  tables  on  a surrogate  IMETS  server  (a  Pentium  450  MHz  Windows  2000  based  laptop 
computer  in  this  case).  These  tables  are  computed  from  algorithms  written  in  the  C programming  language  and  derived  from 
the  ABFA  code.  Currently  the  tables  are  static  for  demonstration  purposes.  However,  they  will  eventually  be  derived  from 
the  gridded  meteorological  database  that  is  resident  on  the  IMETS.  This  database  is  both  temporally  and  spatially  dependent 
and  provides  relatively  high  fidelity  (10  km  in  the  horizontal)  prognostic  (48  hours)  data  from  which  the  propagation  tables 
can  be  computed.  These  tables  will  be  dynamically  updated  twice  daily  when  the  gridded  meteorological  database  is 
refreshed.  Depending  on  the  compute  time  for  the  tables,  they  will  either  be  computed  a priori  and  stored  for  each  grid  point 
or  they  will  be  computed  on  the  fly  for  a specific  grid  point  that  is  nearest  the  location  of  the  mobile  user  requesting  acoustic 
propagation  information.  The  IMETS  gridded  database  is  typically  valid  for  a 500x500  km  domain,  thus  there  are  2601  grid 
points  (51x51)  in  the  horizontal. 

Client  Environment 


The  client  device  is  a Compaq  personal  digital  assistant,  specifically 
model  3650  (see  figure  2).  Although  the  device  weighs  just  over  6 
ounces  and  has  approximate  dimensions  of  5”  x 3.3”  x 0.6”,  it  is  a 
fairly  capable  platform  with  a 206  MHz  processor,  color  display, 
integrated  microphone  and  speaker,  and  32  Mb  of  memory  (newer 
versions  have  64  Mb).  Enhancing  the  device’s  capability  is  the 
PCMCIA1  expansion  pack  option.  This  allows  either  one  or  two  PC 
cards  to  be  integrated  with  the  mobile  platform.  Current  cards 
supported  include  802.11  based  wireless  comms2,  GPS,  additional 
memory  via  compact  flash  cards  or  micro  drives  (up  to  10 
Gigabytes!),  and  VGA  output  to  an  external  display.  Of  primary 
interest  is  the  wireless  capability  which  is  currently  being  used  to 
transmit  and  receive  information  from  the  surrogate  IMETS  server 
over  distances  of  up  to  1000  feet  via  a small  antenna  plugged  into  an 
external  wireless  access  point  connected  to  the  server.  The  wireless 
comms  utilized  for  the  prototype  application  could  be  replaced  with  tactical  comms  for  fielding,  e.g.,  possibly  the  emerging 
Joint  Tactical  Radio  System  (JTRS)  which  will  be  able  to  transmit/receive  both  voice  and  data.  The  GPS  capability  can  be 
integrated  with  the  acoustics  application  to  pass  the  geographic  location  of  the  mobile  device  and  then  query  the  propagation 
tables  nearest  to  that  point.  For  more  detailed  information  regarding  the  mobile  computing  device  and  the  software 
environment  utilized  see  a recent  journal  article  by  Sauter  and  Torres  [2]. 

The  client  application  is  written  in  Java  for  portability  and  potential  transition  to  a fielded  system.  The  code  as  written  and 
compiled  on  a Windows  2000  operating  system  machine  runs  without  recompilation  on  the  Compaq  device  as  well  as 
Windows  95  and  Solaris  based  platforms.  Java’s  remote  method  invocation  (rmi),  a set  of  protocols  to  allow  Java  objects  to 

communicate  with  each  other  remotely,  is  used  for  the  client-server  interaction.  Since  it  was  stated  above  that  the  server 

software  is  written  in  the  C programming  language,  another  interface  is  required  on  the  server  end  to  allow  the  Java  client  to 
access  the  propagation  tables.  This  interface  is  the  Java  Native  Interface  (JNI)  and  allows  Java  objects  to  interact  with  C 
functions.  RMI  and  JNI  are  both  relatively  straightforward  to  work  with  and  did  not  pose  any  challenges  to  the 
implementation  of  the  acoustic  propagation  mobile  application. 


Figure  2 - Compaq  3650  with  802.11  PC  Card 


1 Personal  Computer  Memory  Card  International  Association,  an  organization  of  some  500  companies  that  has  developed  a standard  for  small  credit  card- 
sized devices,  called  PC  Cards  (from  www. webopedia.com). 

2 802.1 1 refers  to  a family  of  specifications  developed  by  the  Institute  of  Electrical  and  Electronics  Engineers  for  wireless  LAN  technology.  802.11  specifies 
an  over-the-air  interface  between  a wireless  client  and  a base  station  or  between  two  wireless  clients  (from  www.webopedia.com). 
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MOBILE  ACOUSTIC  BATTLEFIELD  AID 

Once  the  client  and  server  environments  were  chosen,  it  was  relatively  easy  to 
develop  the  client  application.  A graphical  user  interface  (GUI)  was  developed 
Java  on  a laptop  computer  and  then  copied  to  the  Compaq  mobile  device 
(although  Java  code  can  be  run  on  the  mobiie  device,  there  is  not  a development 
environment  on  it,  thus  code  must  be  compiled  elsewhere  and  transferred). 
While  the  full  Acoustic  Battlefield  Aid  (ABFA)  application  has  numerous  inputs 
and  possible  outputs,  it  was  felt  that  for  a mobile  application,  the  interface 
and  number  of  output  parameters  should  be  kept  simple.  Thus,  an  application 
that  would  provide  the  probability  of  detection  of  an  acoustic  source  by  a sensor 
given  the  range  and  azimuth  between  the  two  was  coded.  Figure  3 displays  the 
actua  mobile  ABFA  GUI  as  it  appears  on  the  mobile  device.  Pull  down 
menus  allow  the  user  to  choose  one  acoustic  source  and  one  sensor.  The  Java 
programming  environment  for  the  mobile  device  is  rather  versatile  and  allows 
for  error  trapping  of  invalid  inputs  (e.g.,  a character  entry  for  a numeric  input 
field  or  an  azimuth  value  > 360  degrees).  In  turn,  the  user  cannot  submit  the 
request  for  the  server  computations  until  all  inputs  contain  valid  entries.  A text 
area  is  used  to  display  pertinent  information  to  the  user  as  is  displayed  in  the 
GUI  in  the  figure.  Sound  can  also  be  added  to  the  client  application  to  alert  the 
user  of  invalid  entries,  problems  with  the  server  or  successful  retrieval  and 
display  of  information  from  the  server. 


For  the  prototype  application  the  source  and  sensor  are  actually  fixed  on  the 
server.  Once  the  user  has  entered  the  range  and  azimuth  and  clicks  the 
“COMPUTE”  button  shown  in  the  lower  left  portion  of  the  GUI,  the  information 
is  transmitted  to  the  surrogate  IMETS  server  over  the  wireless  comms.  The  computations  are  then  made  using  the  static 
propagation  tables  and  the  probability  of  detection  information  is  sent  back  to  the  client  and  displayed.  The  time  from 
“COMPUTE”  to  the  display  of  the  information  on  the  mobile  device  is  typically  a few  seconds.  Depending  on  the 
meteorological  scenario,  the  probability  of  detection  can  vary  greatly  depending  on  not  only  the  range  between  the  source  and 
sensor  but  also  on  the  azimuth.  Acoustic  signals  can  be  transmitted  longer  distances  along  the  downwind  direction  than  in  the 
upwind  direction.  Thus,  if  the  azimuth  is  aligned  in  the  same  direction  as  the  wind  direction  and  the  sensor  is  downwind  of 
the  source,  the  probability  of  detection  can  be  much  larger  than  would  otherwise  be  expected. 

The  Mobile  ABFA  application  should  provide  useful  information  to  the  mobile  user  regarding  detection 
probabilities/distances  not  only  for  enemy  vehicles,  but  also  for  estimating  possible  avenues  of  approach  for  friendly  vehicles 
on  enemy  positions.  For  example,  because  of  terrain  or  other  features  there  may  exist  two  potential  avenues  of  approach  upon 
an  enemy  location.  If  one  is  more  vulnerable  than  the  other  to  acoustic  detection  by  enemy  forces,  a decision  could  be  made 
to  use  the  approach  with  the  lower  probability  of  acoustic  detection.  Depending  on  mobile  user  requirements,  it  would  be 
relatively  simple  to  add  output  parameters  to  the  Mobile  ABFA  application  other  than  the  probability  of  detection.  As  was 
stated  earlier,  there  are  multiple  parameters  that  are  available  from  the  ABFA  program.  Thus,  if  the  user  wanted  to  see 
transmission  loss  that  value  could  be  computed  on  the  server  and  transmitted  back  to  the  mobile  application  for  display. 

FUTURE  CAPABILITIES 

2-D/3-D  Displays 

The  full  ABFA  application  relies  heavily  on  2-D  and  3-D  displays  to  display  spatially  dependent  output  information  to  the 
user  (see  Figure  1).  It  should  be  possible  in  future  versions  of  the  Mobile  ABFA  to  display  some  of  this  information  for  the 
mobile  user.  This  would  be  possible  via  two  separate  methods.  Both  would  involve  the  computation  of  the  spatially 
dependent  information  on  the  server.  In  the  first  method,  the  actual  2-D  or  3-D  display  would  also  be  created  on  the  server 
and  saved  as  a graphics  image  in  the  Joint  Photographic  Experts  Group  format  (jpeg  or  jpg  for  short).  As  the  mobile  device 
has  an  image  viewer  to  display  jpg  images,  the  file  could  be  transmitted  to  the  mobile  user  over  the  wireless  comms  and  then 
loaded  and  displayed.  The  drawback  to  this  approach  is  that  the  bandwidth  for  the  existing  wireless  comms  is  relatively  small 
(1  megabit  per  second  in  theory,  but  in  practice  typically  significantly  less)  and  some  of  these  images  could  be  relatively 
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Figure  3 - Mobile  ABFA  GUI 
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large  (over  1 megabyte).  Thus,  if  there  are  several  mobile  users  requesting  multiple  images  the  transmit  times  could  be  long. 
In  addition,  in  a fielded  version  there  would  be  competing  applications  requiring  use  of  the  wireless  network  effectively 
decreasing  the  bandwidth  even  more.  A second  option  would  involve  transmitting  the  spatially  dependent  information  to  the 
mobile  user  and  then  composing  the  image  on  the  mobile  device.  Commercial  mapping  software  solutions  for  the  Compaq 
3650  do  exist  (e.g.,  ESRTs  ArcPad),  so  in  theory,  this  information  should  be  able  to  be  rendered  on  the  mobile  device.  The 
amount  of  information  required  to  be  transmitted  would  vary  with  the  domain  of  interest  and  the  resolution  of  the  grid  points 
but  should  result  in  a lesser  amount  of  data  transferred  between  server  and  client.  Benchmarking  tests  would  need  to  be 
performed  to  determine  the  tradeoffs/benefits  of  each  method. 


Target  Detection  via  non-Acousiic  Signals 


The  Target  Acquisition 
Weapons  Software 

(TAWS  [3])  provides  lock 
on  and/or  detection  ranges 
for  a wide  variety  of 
electro-optical  sensors  and 
military  targets.  Although 
this  software  is  currently 
written  in  Fortran,  it 
should  be  possible  to 
develop  a mobile  client  in 
Java  that  would  display 
TAWS  output  parameters. 
This  would  compliment 
the  Mobile  ABFA 
application  and  allow  the 
lower  echelon  user  to 
obtain  valuable 

information  regarding 
target  acquisition  in  the 

electro-optical  wavelength  spectrum.  Currently  a version  of  TAWS  is  implemented  in  the  IMETS  and  has  non-map  graphics 
displays  to  represent  the  lock  on  and  detection  ranges  as  bar  charts  (figure  4).  It  is  possible  that  at  some  point  these  bar  charts 
could  be  displayed  on  the  mobile  device,  but  to  start  with  it  may  be  simpler  to  modify  the  existing  Mobile  ABFA  GUI  such 
that  lock  on  and  detection  ranges  can  be  displayed  as  numeric  values  in  the  current  Probability  of  Detection  text  box.  Work  is 
being  finalized  on  a TAWS  map  overlay  capability  in  IMETS  that  will  overlay  the  lock  on  and  detection  ranges  on  a map 
background  over  a 360-degree  azimuth.  This  overlay  will  also  incorporate  the  effects  of  terrain  masking  and  will  color  code 
those  areas  in  a separate  color.  The  discussion  in  the  section  above  related  to  providing  a 2-D  or  3-D  display  on  the  mobile 
device  is  pertinent  to  the  overlay  capability  as  well.  At  some  point,  it  may  also  be  possible  to  animate  these  graphics  over 
time  to  allow  the  user  to  visualize  the  temporal  variation  in  the  transmission  of  the  acoustic  and  electro-optical  signals. 

SUMMARY 

Advances  in  computer  hardware  and  software  technology  have  made  it  possible  to  develop  and  demonstrate  a prototype 
Mobile  Acoustic  BattleField  Aid  on  a handheld  computer.  While  the  current  GUI  and  outputs  are  rather  simplistic,  it  is 
anticipated  that  continued  advances  in  mobile  computing  technology  will  allow  more  advanced  applications  in  the  future. 
Replacing  the  existing  commercial  802.11  wireless  communications  technology  with  the  emerging  Joint  Tactical  Radio 
System  (JTRS)  and  rehosting  the  Java  clients  on  fielded  tactical  command  and  control  systems  may  soon  allow  a target 
detection  capability  at  lower  echelons.  Weather  information  required  as  input  for  these  clients  is  readily  available  (or  will  be 
soon)  at  echelons  down  to  the  battalion  level  via  the  fielded  IMETS. 
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